home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 2001 May / SGI Freeware 2001 May - Disc 2.iso / dist / fw_bzip2.idb / usr / freeware / info / bzip2.info-2.z / bzip2.info-2 (.txt)
GNU Info File  |  2000-06-09  |  41KB  |  811 lines

  1. This is Info file bzip2.info, produced by Makeinfo version 1.68 from
  2. the input file manual.texi.
  3. START-INFO-DIR-ENTRY
  4. * Bzip2: (bzip2).        A program and library for data compression.
  5. END-INFO-DIR-ENTRY
  6. File: bzip2.info,  Node: High-level interface,  Next: Utility functions,  Prev: Low-level interface,  Up: Programming with libbzip2
  7. High-level interface
  8. ====================
  9.    This interface provides functions for reading and writing `bzip2'
  10. format files.  First, some general points.
  11.    * All of the functions take an `int*' first argument,   `bzerror'.
  12.      After each call, `bzerror' should be consulted first to determine
  13.       the outcome of the call.  If `bzerror' is `BZ_OK',   the call
  14.      completed   successfully, and only then should the return value of
  15.      the function   (if any) be consulted.  If `bzerror' is
  16.      `BZ_IO_ERROR',   there was an error   reading/writing the
  17.      underlying compressed file, and you should   then consult
  18.      `errno'/`perror' to determine the   cause of the difficulty.
  19.      `bzerror' may also be set to various other values; precise details
  20.      are   given on a per-function basis below.
  21.    * If `bzerror' indicates an error   (ie, anything except `BZ_OK' and
  22.      `BZ_STREAM_END'),   you should immediately call `bzReadClose' (or
  23.      `bzWriteClose',   depending on whether you are attempting to read
  24.      or to write)   to free up all resources associated   with the
  25.      stream.  Once an error has been indicated, behaviour of all calls
  26.      except `bzReadClose' (`bzWriteClose') is undefined.    The
  27.      implication is that (1) `bzerror' should   be checked after each
  28.      call, and (2) if `bzerror' indicates an error,   `bzReadClose'
  29.      (`bzWriteClose') should then be called to clean up.
  30.    * The `FILE*' arguments passed to    `bzReadOpen'/`bzWriteOpen'
  31.      should be set to binary mode.    Most Unix systems will do this by
  32.      default, but other platforms,   including Windows and Mac, will
  33.      not.  If you omit this, you may   encounter problems when moving
  34.      code to new platforms.
  35.    * Memory allocation requests are handled by   `malloc'/`free'.    At
  36.      present   there is no facility for user-defined memory allocators
  37.      in the file I/O   functions (could easily be added, though).
  38. `bzReadOpen'
  39. ------------
  40.         typedef void BZFILE;
  41.      
  42.         BZFILE *bzReadOpen ( int *bzerror, FILE *f,
  43.                              int small, int verbosity,
  44.                              void *unused, int nUnused );
  45.    Prepare to read compressed data from file handle `f'.  `f' should
  46. refer to a file which has been opened for reading, and for which the
  47. error indicator (`ferror(f)')is not set.  If `small' is 1, the library
  48. will try to decompress using less memory, at the expense of speed.
  49.    For reasons explained below, `bzRead' will decompress the `nUnused'
  50. bytes starting at `unused', before starting to read from the file `f'.
  51. At most `BZ_MAX_UNUSED' bytes may be supplied like this.  If this
  52. facility is not required, you should pass `NULL' and `0' for `unused'
  53. and n`Unused' respectively.
  54.    For the meaning of parameters `small' and `verbosity', see
  55. `bzDecompressInit'.
  56.    The amount of memory needed to decompress a file cannot be determined
  57. until the file's header has been read.  So it is possible that
  58. `bzReadOpen' returns `BZ_OK' but a subsequent call of `bzRead' will
  59. return `BZ_MEM_ERROR'.
  60.    Possible assignments to `bzerror':
  61.            `BZ_PARAM_ERROR'
  62.               if `f' is `NULL'
  63.               or `small' is neither `0' nor `1'
  64.               or `(unused == NULL && nUnused != 0)'
  65.               or `(unused != NULL && !(0 <= nUnused <= BZ_MAX_UNUSED))'
  66.            `BZ_IO_ERROR'
  67.               if `ferror(f)' is nonzero
  68.            `BZ_MEM_ERROR'
  69.               if insufficient memory is available
  70.            `BZ_OK'
  71.               otherwise.
  72.    Possible return values:
  73.            Pointer to an abstract `BZFILE'
  74.               if `bzerror' is `BZ_OK'
  75.            `NULL'
  76.               otherwise
  77.    Allowable next actions:
  78.            `bzRead'
  79.               if `bzerror' is `BZ_OK'
  80.            `bzClose'
  81.               otherwise
  82. `bzRead'
  83. --------
  84.         int bzRead ( int *bzerror, BZFILE *b, void *buf, int len );
  85.    Reads up to `len' (uncompressed) bytes from the compressed file `b'
  86. into the buffer `buf'.  If the read was successful, `bzerror' is set to
  87. `BZ_OK' and the number of bytes read is returned.  If the logical
  88. end-of-stream was detected, `bzerror' will be set to `BZ_STREAM_END',
  89. and the number of bytes read is returned.  All other `bzerror' values
  90. denote an error.
  91.    `bzRead' will supply `len' bytes, unless the logical stream end is
  92. detected or an error occurs.  Because of this, it is possible to detect
  93. the stream end by observing when the number of bytes returned is less
  94. than the number requested.  Nevertheless, this is regarded as
  95. inadvisable; you should instead check `bzerror' after every call and
  96. watch out for `BZ_STREAM_END'.
  97.    Internally, `bzRead' copies data from the compressed file in chunks
  98. of size `BZ_MAX_UNUSED' bytes before decompressing it.  If the file
  99. contains more bytes than strictly needed to reach the logical
  100. end-of-stream, `bzRead' will almost certainly read some of the trailing
  101. data before signalling `BZ_SEQUENCE_END'.  To collect the read but
  102. unused data once `BZ_SEQUENCE_END' has appeared, call `bzReadGetUnused'
  103. immediately before `bzReadClose'.
  104.    Possible assignments to `bzerror':
  105.            `BZ_PARAM_ERROR'
  106.               if `b' is `NULL' or `buf' is `NULL' or `len < 0'
  107.            `BZ_SEQUENCE_ERROR'
  108.               if `b' was opened with `bzWriteOpen'
  109.            `BZ_IO_ERROR'
  110.               if there is an error reading from the compressed file
  111.            `BZ_UNEXPECTED_EOF'
  112.               if the compressed file ended before the logical end-of-stream was detected
  113.            `BZ_DATA_ERROR'
  114.               if a data integrity error was detected in the compressed stream
  115.            `BZ_DATA_ERROR_MAGIC'
  116.               if the stream does not begin with the requisite header bytes (ie, is not
  117.               a `bzip2' data file).  This is really a special case of `BZ_DATA_ERROR'.
  118.            `BZ_MEM_ERROR'
  119.               if insufficient memory was available
  120.            `BZ_STREAM_END'
  121.               if the logical end of stream was detected.
  122.            `BZ_OK'
  123.               otherwise.
  124.    Possible return values:
  125.            number of bytes read
  126.               if `bzerror' is `BZ_OK' or `BZ_STREAM_END'
  127.            undefined
  128.               otherwise
  129.    Allowable next actions:
  130.            collect data from `buf', then `bzRead' or `bzReadClose'
  131.               if `bzerror' is `BZ_OK'
  132.            collect data from `buf', then `bzReadClose' or `bzReadGetUnused'
  133.               if `bzerror' is `BZ_SEQUENCE_END'
  134.            `bzReadClose'
  135.               otherwise
  136. `bzReadGetUnused'
  137. -----------------
  138.         void bzReadGetUnused ( int* bzerror, BZFILE *b,
  139.                                void** unused, int* nUnused );
  140.    Returns data which was read from the compressed file but was not
  141. needed to get to the logical end-of-stream.  `*unused' is set to the
  142. address of the data, and `*nUnused' to the number of bytes.  `*nUnused'
  143. will be set to a value between `0' and `BZ_MAX_UNUSED' inclusive.
  144.    This function may only be called once `bzRead' has signalled
  145. `BZ_STREAM_END' but before `bzReadClose'.
  146.    Possible assignments to `bzerror':
  147.            `BZ_PARAM_ERROR'
  148.               if `b' is `NULL'
  149.               or `unused' is `NULL' or `nUnused' is `NULL'
  150.            `BZ_SEQUENCE_ERROR'
  151.               if `BZ_STREAM_END' has not been signalled
  152.               or if `b' was opened with `bzWriteOpen'
  153.           `BZ_OK'
  154.               otherwise
  155.    Allowable next actions:
  156.            `bzReadClose'
  157. `bzReadClose'
  158. -------------
  159.         void bzReadClose ( int *bzerror, BZFILE *b );
  160.    Releases all memory pertaining to the compressed file `b'.
  161. `bzReadClose' does not call `fclose' on the underlying file handle, so
  162. you should do that yourself if appropriate.  `bzReadClose' should be
  163. called to clean up after all error situations.
  164.    Possible assignments to `bzerror':
  165.            `BZ_SEQUENCE_ERROR'
  166.               if `b' was opened with `bzOpenWrite'
  167.            `BZ_OK'
  168.               otherwise
  169.    Allowable next actions:
  170.            none
  171. `bzWriteOpen'
  172. -------------
  173.         BZFILE *bzWriteOpen ( int *bzerror, FILE *f,
  174.                               int blockSize100k, int verbosity,
  175.                               int workFactor );
  176.    Prepare to write compressed data to file handle `f'.  `f' should
  177. refer to a file which has been opened for writing, and for which the
  178. error indicator (`ferror(f)')is not set.
  179.    For the meaning of parameters `blockSize100k', `verbosity' and
  180. `workFactor', see
  181. `bzCompressInit'.
  182.    All required memory is allocated at this stage, so if the call
  183. completes successfully, `BZ_MEM_ERROR' cannot be signalled by a
  184. subsequent call to `bzWrite'.
  185.    Possible assignments to `bzerror':
  186.            `BZ_PARAM_ERROR'
  187.               if `f' is `NULL'
  188.               or `blockSize100k < 1' or `blockSize100k > 9'
  189.            `BZ_IO_ERROR'
  190.               if `ferror(f)' is nonzero
  191.            `BZ_MEM_ERROR'
  192.               if insufficient memory is available
  193.            `BZ_OK'
  194.               otherwise
  195.    Possible return values:
  196.            Pointer to an abstract `BZFILE'
  197.               if `bzerror' is `BZ_OK'
  198.            `NULL'
  199.               otherwise
  200.    Allowable next actions:
  201.            `bzWrite'
  202.               if `bzerror' is `BZ_OK'
  203.               (you could go directly to `bzWriteClose', but this would be pretty pointless)
  204.            `bzWriteClose'
  205.               otherwise
  206. `bzWrite'
  207. ---------
  208.         void bzWrite ( int *bzerror, BZFILE *b, void *buf, int len );
  209.    Absorbs `len' bytes from the buffer `buf', eventually to be
  210. compressed and written to the file.
  211.    Possible assignments to `bzerror':
  212.            `BZ_PARAM_ERROR'
  213.               if `b' is `NULL' or `buf' is `NULL' or `len < 0'
  214.            `BZ_SEQUENCE_ERROR'
  215.               if b was opened with `bzReadOpen'
  216.            `BZ_IO_ERROR'
  217.               if there is an error writing the compressed file.
  218.            `BZ_OK'
  219.               otherwise
  220. `bzWriteClose'
  221. --------------
  222.         int bzWriteClose ( int *bzerror, BZFILE* f,
  223.                            int abandon,
  224.                            unsigned int* nbytes_in,
  225.                            unsigned int* nbytes_out );
  226.    Compresses and flushes to the compressed file all data so far
  227. supplied by `bzWrite'.  The logical end-of-stream markers are also
  228. written, so subsequent calls to `bzWrite' are illegal.  All memory
  229. associated with the compressed file `b' is released.  `fflush' is
  230. called on the compressed file, but it is not `fclose''d.
  231.    If `bzWriteClose' is called to clean up after an error, the only
  232. action is to release the memory.  The library records the error codes
  233. issued by previous calls, so this situation will be detected
  234. automatically.  There is no attempt to complete the compression
  235. operation, nor to `fflush' the compressed file.  You can force this
  236. behaviour to happen even in the case of no error, by passing a nonzero
  237. value to `abandon'.
  238.    If `nbytes_in' is non-null, `*nbytes_in' will be set to be the total
  239. volume of uncompressed data handled.  Similarly, `nbytes_out' will be
  240. set to the total volume of compressed data written.
  241.    Possible assignments to `bzerror':
  242.            `BZ_SEQUENCE_ERROR'
  243.               if `b' was opened with `bzReadOpen'
  244.            `BZ_IO_ERROR'
  245.               if there is an error writing the compressed file
  246.            `BZ_OK'
  247.               otherwise
  248. Handling embedded compressed data streams
  249. -----------------------------------------
  250.    The high-level library facilitates use of `bzip2' data streams which
  251. form some part of a surrounding, larger data stream.
  252.    * For writing, the library takes an open file handle, writes
  253.      compressed data to it, `fflush'es it but does not `fclose' it.
  254.      The calling application can write its own data before and after the
  255.      compressed data stream, using that same file handle.
  256.    * Reading is more complex, and the facilities are not as general as
  257.      they could be since generality is hard to reconcile with
  258.      efficiency.  `bzRead' reads from the compressed file in blocks of
  259.      size `BZ_MAX_UNUSED' bytes, and in doing so probably will overshoot
  260.      the logical end of compressed stream.  To recover this data once
  261.      decompression has ended, call `bzReadGetUnused' after the last
  262.      call of `bzRead' (the one returning `BZ_STREAM_END') but before
  263.      calling `bzReadClose'.
  264.    This mechanism makes it easy to decompress multiple `bzip2' streams
  265. placed end-to-end.  As the end of one stream, when `bzRead' returns
  266. `BZ_STREAM_END', call `bzReadGetUnused' to collect the unused data
  267. (copy it into your own buffer somewhere).  That data forms the start of
  268. the next compressed stream.  To start uncompressing that next stream,
  269. call `bzReadOpen' again, feeding in the unused data via the
  270. `unused'/`nUnused' parameters.  Keep doing this until `BZ_STREAM_END'
  271. return coincides with the physical end of file (`feof(f)').  In this
  272. situation `bzReadGetUnused' will of course return no data.
  273.    This should give some feel for how the high-level interface can be
  274. used.  If you require extra flexibility, you'll have to bite the bullet
  275. and get to grips with the low-level interface.
  276. Standard file-reading/writing code
  277. ----------------------------------
  278.    Here's how you'd write data to a compressed file:
  279.      FILE*   f;
  280.      BZFILE* b;
  281.      int     nBuf;
  282.      char    buf[ /* whatever size you like */ ];
  283.      int     bzerror;
  284.      int     nWritten;
  285.      
  286.      f = fopen ( "myfile.bz2", "w" );
  287.      if (!f) {
  288.         /* handle error */
  289.      }
  290.      b = bzWriteOpen ( &bzerror, f, 9 );
  291.      if (bzerror != BZ_OK) {
  292.         bzWriteClose ( b );
  293.         /* handle error */
  294.      }
  295.      
  296.      while ( /* condition */ ) {
  297.         /* get data to write into buf, and set nBuf appropriately */
  298.         nWritten = bzWrite ( &bzerror, b, buf, nBuf );
  299.         if (bzerror == BZ_IO_ERROR) {
  300.            bzWriteClose ( &bzerror, b );
  301.            /* handle error */
  302.         }
  303.      }
  304.      
  305.      bzWriteClose ( &bzerror, b );
  306.      if (bzerror == BZ_IO_ERROR) {
  307.         /* handle error */
  308.      }
  309.    And to read from a compressed file:
  310.      FILE*   f;
  311.      BZFILE* b;
  312.      int     nBuf;
  313.      char    buf[ /* whatever size you like */ ];
  314.      int     bzerror;
  315.      int     nWritten;
  316.      
  317.      f = fopen ( "myfile.bz2", "r" );
  318.      if (!f) {
  319.         /* handle error */
  320.      }
  321.      b = bzReadOpen ( &bzerror, f, 0, NULL, 0 );
  322.      if (bzerror != BZ_OK) {
  323.         bzReadClose ( &bzerror, b );
  324.         /* handle error */
  325.      }
  326.      
  327.      bzerror = BZ_OK;
  328.      while (bzerror == BZ_OK && /* arbitrary other conditions */) {
  329.         nBuf = bzRead ( &bzerror, b, buf, /* size of buf */ );
  330.         if (bzerror == BZ_OK) {
  331.            /* do something with buf[0 .. nBuf-1] */
  332.         }
  333.      }
  334.      if (bzerror != BZ_STREAM_END) {
  335.         bzReadClose ( &bzerror, b );
  336.         /* handle error */
  337.      } else {
  338.         bzReadClose ( &bzerror );
  339.      }
  340. File: bzip2.info,  Node: Utility functions,  Next: zlib compatibility functions,  Prev: High-level interface,  Up: Programming with libbzip2
  341. Utility functions
  342. =================
  343. `bzBuffToBuffCompress'
  344. ----------------------
  345.         int bzBuffToBuffCompress( char*         dest,
  346.                                   unsigned int* destLen,
  347.                                   char*         source,
  348.                                   unsigned int  sourceLen,
  349.                                   int           blockSize100k,
  350.                                   int           verbosity,
  351.                                   int           workFactor );
  352.    Attempts to compress the data in `source[0 .. sourceLen-1]' into the
  353. destination buffer, `dest[0 .. *destLen-1]'.  If the destination buffer
  354. is big enough, `*destLen' is set to the size of the compressed data,
  355. and `BZ_OK' is returned.  If the compressed data won't fit, `*destLen'
  356. is unchanged, and `BZ_OUTBUFF_FULL' is returned.
  357.    Compression in this manner is a one-shot event, done with a single
  358. call to this function.  The resulting compressed data is a complete
  359. `bzip2' format data stream.  There is no mechanism for making
  360. additional calls to provide extra input data.  If you want that kind of
  361. mechanism, use the low-level interface.
  362.    For the meaning of parameters `blockSize100k', `verbosity' and
  363. `workFactor',
  364. see `bzCompressInit'.
  365.    To guarantee that the compressed data will fit in its buffer,
  366. allocate an output buffer of size 1% larger than the uncompressed data,
  367. plus six hundred extra bytes.
  368.    `bzBuffToBuffDecompress' will not write data at or beyond
  369. `dest[*destLen]', even in case of buffer overflow.
  370.    Possible return values:
  371.            `BZ_PARAM_ERROR'
  372.               if `dest' is `NULL' or `destLen' is `NULL'
  373.               or `blockSize100k < 1' or `blockSize100k > 9'
  374.               or `verbosity < 0' or `verbosity > 4'
  375.               or `workFactor < 0' or `workFactor > 250'
  376.            `BZ_MEM_ERROR'
  377.               if insufficient memory is available
  378.            `BZ_OUTBUFF_FULL'
  379.               if the size of the compressed data exceeds `*destLen'
  380.            `BZ_OK'
  381.               otherwise
  382. `bzBuffToBuffDecompress'
  383. ------------------------
  384.         int bzBuffToBuffDecompress ( char*         dest,
  385.                                      unsigned int* destLen,
  386.                                      char*         source,
  387.                                      unsigned int  sourceLen,
  388.                                      int           small,
  389.                                      int           verbosity );
  390.    Attempts to decompress the data in `source[0 .. sourceLen-1]' into
  391. the destination buffer, `dest[0 .. *destLen-1]'.  If the destination
  392. buffer is big enough, `*destLen' is set to the size of the uncompressed
  393. data, and `BZ_OK' is returned.  If the compressed data won't fit,
  394. `*destLen' is unchanged, and `BZ_OUTBUFF_FULL' is returned.
  395.    `source' is assumed to hold a complete `bzip2' format data stream.
  396. `bzBuffToBuffDecompress' tries to decompress the entirety of the stream
  397. into the output buffer.
  398.    For the meaning of parameters `small' and `verbosity', see
  399. `bzDecompressInit'.
  400.    Because the compression ratio of the compressed data cannot be known
  401. in advance, there is no easy way to guarantee that the output buffer
  402. will be big enough.  You may of course make arrangements in your code to
  403. record the size of the uncompressed data, but such a mechanism is beyond
  404. the scope of this library.
  405.    `bzBuffToBuffDecompress' will not write data at or beyond
  406. `dest[*destLen]', even in case of buffer overflow.
  407.    Possible return values:
  408.            `BZ_PARAM_ERROR'
  409.               if `dest' is `NULL' or `destLen' is `NULL'
  410.               or `small != 0 && small != 1'
  411.               or `verbosity < 0' or `verbosity > 4'
  412.            `BZ_MEM_ERROR'
  413.               if insufficient memory is available
  414.            `BZ_OUTBUFF_FULL'
  415.               if the size of the compressed data exceeds `*destLen'
  416.            `BZ_DATA_ERROR'
  417.               if a data integrity error was detected in the compressed data
  418.            `BZ_DATA_ERROR_MAGIC'
  419.               if the compressed data doesn't begin with the right magic bytes
  420.            `BZ_UNEXPECTED_EOF'
  421.               if the compressed data ends unexpectedly
  422.            `BZ_OK'
  423.               otherwise
  424. File: bzip2.info,  Node: zlib compatibility functions,  Next: Using the library in a stdio-free environment,  Prev: Utility functions,  Up: Programming with libbzip2
  425. `zlib' compatibility functions
  426. ==============================
  427.    Yoshioka Tsuneo has contributed some functions to give better `zlib'
  428. compatibility.  These functions are `bzopen', `bzread', `bzwrite',
  429. `bzflush', `bzclose', `bzerror' and `bzlibVersion'.  These functions
  430. are not (yet) officially part of the library.  If they break, you get
  431. to keep all the pieces.  Nevertheless, I think they work ok.
  432.      typedef void BZFILE;
  433.      
  434.      const char * bzlibVersion ( void );
  435.    Returns a string indicating the library version.
  436.      BZFILE * bzopen  ( const char *path, const char *mode );
  437.      BZFILE * bzdopen ( int        fd,    const char *mode );
  438.    Opens a `.bz2' file for reading or writing, using either its name or
  439. a pre-existing file descriptor.  Analogous to `fopen' and `fdopen'.
  440.      int bzread  ( BZFILE* b, void* buf, int len );
  441.      int bzwrite ( BZFILE* b, void* buf, int len );
  442.    Reads/writes data from/to a previously opened `BZFILE'.  Analogous
  443. to `fread' and `fwrite'.
  444.      int  bzflush ( BZFILE* b );
  445.      void bzclose ( BZFILE* b );
  446.    Flushes/closes a `BZFILE'.  `bzflush' doesn't actually do anything.
  447. Analogous to `fflush' and `fclose'.
  448.      const char * bzerror ( BZFILE *b, int *errnum )
  449.    Returns a string describing the more recent error status of `b', and
  450. also sets `*errnum' to its numerical value.
  451. File: bzip2.info,  Node: Using the library in a stdio-free environment,  Next: Making a Windows DLL,  Prev: zlib compatibility functions,  Up: Programming with libbzip2
  452. Using the library in a `stdio'-free environment
  453. ===============================================
  454. Getting rid of `stdio'
  455. ----------------------
  456.    In a deeply embedded application, you might want to use just the
  457. memory-to-memory functions.  You can do this conveniently by compiling
  458. the library with preprocessor symbol `BZ_NO_STDIO' defined.  Doing this
  459. gives you a library containing only the following eight functions:
  460.    `bzCompressInit', `bzCompress', `bzCompressEnd'
  461. `bzDecompressInit', `bzDecompress', `bzDecompressEnd'
  462. `bzBuffToBuffCompress', `bzBuffToBuffDecompress'
  463.    When compiled like this, all functions will ignore `verbosity'
  464. settings.
  465. Critical error handling
  466. -----------------------
  467.    `libbzip2' contains a number of internal assertion checks which
  468. should, needless to say, never be activated.  Nevertheless, if an
  469. assertion should fail, behaviour depends on whether or not the library
  470. was compiled with `BZ_NO_STDIO' set.
  471.    For a normal compile, an assertion failure yields the message
  472.         bzip2/libbzip2, v0.9.5: internal error number N.
  473.         This is a bug in bzip2/libbzip2, v0.9.5.  Please report
  474.         it to me at: jseward@acm.org.  If this happened when
  475.         you were using some program which uses libbzip2 as a
  476.         component, you should also report this bug to the author(s)
  477.         of that program.  Please make an effort to report this bug;
  478.         timely and accurate bug reports eventually lead to higher
  479.         quality software.  Thanks.  Julian Seward, 24 May 1999.
  480.    where `N' is some error code number.  `exit(3)' is then called.
  481.    For a `stdio'-free library, assertion failures result in a call to a
  482. function declared as:
  483.         extern void bz_internal_error ( int errcode );
  484.    The relevant code is passed as a parameter.  You should supply such
  485. a function.
  486.    In either case, once an assertion failure has occurred, any
  487. `bz_stream' records involved can be regarded as invalid.  You should
  488. not attempt to resume normal operation with them.
  489.    You may, of course, change critical error handling to suit your
  490. needs.  As I said above, critical errors indicate bugs in the library
  491. and should not occur.  All "normal" error situations are indicated via
  492. error return codes from functions, and can be recovered from.
  493. File: bzip2.info,  Node: Making a Windows DLL,  Prev: Using the library in a stdio-free environment,  Up: Programming with libbzip2
  494. Making a Windows DLL
  495. ====================
  496.    Everything related to Windows has been contributed by Yoshioka Tsuneo
  497. (`QWF00133@niftyserve.or.jp' / `tsuneo-y@is.aist-nara.ac.jp'), so you
  498. should send your queries to him (but perhaps Cc: me, `jseward@acm.org').
  499.    My vague understanding of what to do is: using Visual C++ 5.0, open
  500. the project file `libbz2.dsp', and build.  That's all.
  501.    If you can't open the project file for some reason, make a new one,
  502. naming these files: `blocksort.c', `bzlib.c', `compress.c',
  503. `crctable.c', `decompress.c', `huffman.c',
  504. `randtable.c' and `libbz2.def'.  You will also need to name the header
  505. files `bzlib.h' and `bzlib_private.h'.
  506.    If you don't use VC++, you may need to define the proprocessor symbol
  507. `_WIN32'.
  508.    Finally, `dlltest.c' is a sample program using the DLL.  It has a
  509. project file, `dlltest.dsp'.
  510.    If you just want a makefile for Visual C, have a look at
  511. `makefile.msc'.
  512.    Be aware that if you compile `bzip2' itself on Win32, you must set
  513. `BZ_UNIX' to 0 and `BZ_LCCWIN32' to 1, in the file `bzip2.c', before
  514. compiling.  Otherwise the resulting binary won't work correctly.
  515.    I haven't tried any of this stuff myself, but it all looks plausible.
  516. File: bzip2.info,  Node: Miscellanea,  Prev: Programming with libbzip2,  Up: Top
  517. Miscellanea
  518. ***********
  519.    These are just some random thoughts of mine.  Your mileage may vary.
  520. * Menu:
  521. * Limitations of the compressed file format::
  522. * Portability issues::
  523. * Reporting bugs::
  524. * Did you get the right package?::
  525. * Testing::
  526. * Further reading::
  527. File: bzip2.info,  Node: Limitations of the compressed file format,  Next: Portability issues,  Prev: Miscellanea,  Up: Miscellanea
  528. Limitations of the compressed file format
  529. =========================================
  530.    `bzip2-0.9.5' and `0.9.0' use exactly the same file format as the
  531. previous version, `bzip2-0.1'.  This decision was made in the interests
  532. of stability.  Creating yet another incompatible compressed file format
  533. would create further confusion and disruption for users.
  534.    Nevertheless, this is not a painless decision.  Development work
  535. since the release of `bzip2-0.1' in August 1997 has shown complexities
  536. in the file format which slow down decompression and, in retrospect,
  537. are unnecessary.  These are:
  538.    * The run-length encoder, which is the first of the
  539.      compression transformations, is entirely irrelevant.        The
  540.      original purpose was to protect the sorting algorithm       from
  541.      the very worst case input: a string of repeated       symbols.
  542.      But algorithm steps Q6a and Q6b in the original
  543.      Burrows-Wheeler technical report (SRC-124) show how       repeats
  544.      can be handled without difficulty in block       sorting.
  545.    * The randomisation mechanism doesn't really need to be       there.
  546.      Udi Manber and Gene Myers published a suffix       array
  547.      construction algorithm a few years back, which       can be
  548.      employed to sort any block, no matter how       repetitive, in O(N
  549.      log N) time.  Subsequent work by       Kunihiko Sadakane has
  550.      produced a derivative O(N (log N)^2)       algorithm which usually
  551.      outperforms the Manber-Myers       algorithm.
  552.      I could have changed to Sadakane's algorithm, but I find       it
  553.      to be slower than `bzip2''s existing algorithm for       most
  554.      inputs, and the randomisation mechanism protects       adequately
  555.      against bad cases.  I didn't think it was       a good tradeoff to
  556.      make.  Partly this is due to the fact       that I was not flooded
  557.      with email complaints about       `bzip2-0.1''s performance on
  558.      repetitive data, so       perhaps it isn't a problem for real
  559.      inputs.
  560.      Probably the best long-term solution,       and the one I have
  561.      incorporated into 0.9.5 and above,       is to use the existing
  562.      sorting       algorithm initially, and fall back to a O(N (log
  563.      N)^2)       algorithm if the standard algorithm gets into
  564.      difficulties.
  565.    * The compressed file format was never designed to be       handled
  566.      by a library, and I have had to jump though       some hoops to
  567.      produce an efficient implementation of       decompression.  It's
  568.      a bit hairy.  Try passing       `decompress.c' through the C
  569.      preprocessor       and you'll see what I mean.  Much of this
  570.      complexity       could have been avoided if the compressed size of
  571.           each block of data was recorded in the data stream.
  572.    * An Adler-32 checksum, rather than a CRC32 checksum,       would be
  573.      faster to compute.  It would be fair to say that the `bzip2'
  574. format was frozen before I properly and fully understood the performance
  575. consequences of doing so.
  576.    Improvements which I was able to incorporate into 0.9.0, despite
  577. using the same file format, are:
  578.    * Single array implementation of the inverse BWT.  This
  579.      significantly speeds up decompression, presumably       because it
  580.      reduces the number of cache misses.
  581.    * Faster inverse MTF transform for large MTF values.  The       new
  582.      implementation is based on the notion of sliding blocks       of
  583.      values.
  584.    * `bzip2-0.9.0' now reads and writes files with `fread'       and
  585.      `fwrite'; version 0.1 used `putc' and `getc'.        Duh!  Well,
  586.      you live and learn.
  587.    Further ahead, it would be nice to be able to do random access into
  588. files.  This will require some careful design of compressed file
  589. formats.
  590. File: bzip2.info,  Node: Portability issues,  Next: Reporting bugs,  Prev: Limitations of the compressed file format,  Up: Miscellanea
  591. Portability issues
  592. ==================
  593.    After some consideration, I have decided not to use GNU `autoconf'
  594. to configure 0.9.5.
  595.    `autoconf', admirable and wonderful though it is, mainly assists
  596. with portability problems between Unix-like platforms.  But `bzip2'
  597. doesn't have much in the way of portability problems on Unix; most of
  598. the difficulties appear when porting to the Mac, or to Microsoft's
  599. operating systems.  `autoconf' doesn't help in those cases, and brings
  600. in a whole load of new complexity.
  601.    Most people should be able to compile the library and program under
  602. Unix straight out-of-the-box, so to speak, especially if you have a
  603. version of GNU C available.
  604.    There are a couple of `__inline__' directives in the code.  GNU C
  605. (`gcc') should be able to handle them.  If you're not using GNU C, your
  606. C compiler shouldn't see them at all.  If your compiler does, for some
  607. reason, see them and doesn't like them, just `#define' `__inline__' to
  608. be `/* */'.  One easy way to do this is to compile with the flag
  609. `-D__inline__=', which should be understood by most Unix compilers.
  610.    If you still have difficulties, try compiling with the macro
  611. `BZ_STRICT_ANSI' defined.  This should enable you to build the library
  612. in a strictly ANSI compliant environment.  Building the program itself
  613. like this is dangerous and not supported, since you remove `bzip2''s
  614. checks against compressing directories, symbolic links, devices, and
  615. other not-really-a-file entities.  This could cause filesystem
  616. corruption!
  617.    One other thing: if you create a `bzip2' binary for public
  618. distribution, please try and link it statically (`gcc -s').  This
  619. avoids all sorts of library-version issues that others may encounter
  620. later on.
  621.    If you build `bzip2' on Win32, you must set `BZ_UNIX' to 0 and
  622. `BZ_LCCWIN32' to 1, in the file `bzip2.c', before compiling.  Otherwise
  623. the resulting binary won't work correctly.
  624. File: bzip2.info,  Node: Reporting bugs,  Next: Did you get the right package?,  Prev: Portability issues,  Up: Miscellanea
  625. Reporting bugs
  626. ==============
  627.    I tried pretty hard to make sure `bzip2' is bug free, both by design
  628. and by testing.  Hopefully you'll never need to read this section for
  629. real.
  630.    Nevertheless, if `bzip2' dies with a segmentation fault, a bus error
  631. or an internal assertion failure, it will ask you to email me a bug
  632. report.  Experience with version 0.1 shows that almost all these
  633. problems can be traced to either compiler bugs or hardware problems.
  634.    * Recompile the program with no optimisation, and see if it works.
  635.      And/or try a different compiler.  I heard all sorts of stories
  636.      about various flavours of GNU C (and other compilers) generating
  637.      bad code for `bzip2', and I've run across two such examples myself.
  638.      2.7.X versions of GNU C are known to generate bad code from time
  639.      to time, at high optimisation levels.  If you get problems, try
  640.      using the flags `-O2' `-fomit-frame-pointer'
  641.      `-fno-strength-reduce'.  You should specifically *not* use
  642.      `-funroll-loops'.
  643.      You may notice that the Makefile runs four tests as part of the
  644.      build process.  If the program passes all of these, it's a pretty
  645.      good (but not 100%) indication that the compiler has done its job
  646.      correctly.
  647.    * If `bzip2' crashes randomly, and the crashes are not repeatable,
  648.      you may have a flaky memory subsystem.  `bzip2' really hammers
  649.      your memory hierarchy, and if it's a bit marginal, you may get
  650.      these problems.  Ditto if your disk or I/O subsystem is slowly
  651.      failing.  Yup, this really does happen.
  652.      Try using a different machine of the same type, and see if you can
  653.      repeat the problem.
  654.    * This isn't really a bug, but ... If `bzip2' tells you your file is
  655.      corrupted on decompression, and you obtained the file via FTP,
  656.      there is a possibility that you forgot to tell FTP to do a binary
  657.      mode transfer.  That absolutely will cause the file to be
  658.      non-decompressible.  You'll have to transfer it again.
  659.    If you've incorporated `libbzip2' into your own program and are
  660. getting problems, please, please, please, check that the parameters you
  661. are passing in calls to the library, are correct, and in accordance
  662. with what the documentation says is allowable.  I have tried to make
  663. the library robust against such problems, but I'm sure I haven't
  664. succeeded.
  665.    Finally, if the above comments don't help, you'll have to send me a
  666. bug report.  Now, it's just amazing how many people will send me a bug
  667. report saying something like
  668.         bzip2 crashed with segmentation fault on my machine
  669.    and absolutely nothing else.  Needless to say, a such a report is
  670. *totally, utterly, completely and comprehensively 100% useless; a waste
  671. of your time, my time, and net bandwidth*.  With no details at all,
  672. there's no way I can possibly begin to figure out what the problem is.
  673.    The rules of the game are: facts, facts, facts.  Don't omit them
  674. because "oh, they won't be relevant".  At the bare minimum:
  675.         Machine type.  Operating system version.
  676.         Exact version of `bzip2' (do `bzip2 -V').
  677.         Exact version of the compiler used.
  678.         Flags passed to the compiler.
  679.    However, the most important single thing that will help me is the
  680. file that you were trying to compress or decompress at the time the
  681. problem happened.  Without that, my ability to do anything more than
  682. speculate about the cause, is limited.
  683.    Please remember that I connect to the Internet with a modem, so you
  684. should contact me before mailing me huge files.
  685. File: bzip2.info,  Node: Did you get the right package?,  Next: Testing,  Prev: Reporting bugs,  Up: Miscellanea
  686. Did you get the right package?
  687. ==============================
  688.    `bzip2' is a resource hog.  It soaks up large amounts of CPU cycles
  689. and memory.  Also, it gives very large latencies.  In the worst case,
  690. you can feed many megabytes of uncompressed data into the library before
  691. getting any compressed output, so this probably rules out applications
  692. requiring interactive behaviour.
  693.    These aren't faults of my implementation, I hope, but more an
  694. intrinsic property of the Burrows-Wheeler transform (unfortunately).
  695. Maybe this isn't what you want.
  696.    If you want a compressor and/or library which is faster, uses less
  697. memory but gets pretty good compression, and has minimal latency,
  698. consider Jean-loup Gailly's and Mark Adler's work, `zlib-1.1.2' and
  699. `gzip-1.2.4'.  Look for them at `http://www.cdrom.com/pub/infozip/zlib'
  700. and `http://www.gzip.org' respectively.
  701.    For something faster and lighter still, you might try Markus F X J
  702. Oberhumer's `LZO' real-time compression/decompression library, at
  703. `http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html'.
  704.    If you want to use the `bzip2' algorithms to compress small blocks
  705. of data, 64k bytes or smaller, for example on an on-the-fly disk
  706. compressor, you'd be well advised not to use this library.  Instead,
  707. I've made a special library tuned for that kind of use.  It's part of
  708. `e2compr-0.40', an on-the-fly disk compressor for the Linux `ext2'
  709. filesystem.  Look at `http://www.netspace.net.au/~reiter/e2compr'.
  710. File: bzip2.info,  Node: Testing,  Next: Further reading,  Prev: Did you get the right package?,  Up: Miscellanea
  711. Testing
  712. =======
  713.    A record of the tests I've done.
  714.    First, some data sets:
  715.    * B: a directory containing 6001 files, one for every length in the
  716.          range 0 to 6000 bytes.  The files contain random lowercase
  717.        letters.  18.7 megabytes.
  718.    * H: my home directory tree.  Documents, source code, mail files,
  719.        compressed data.  H contains B, and also a directory of
  720.      files designed as boundary cases for the sorting; mostly very
  721.      repetitive, nasty files.  565 megabytes.
  722.    * A: directory tree holding various applications built from source:
  723.          `egcs', `gcc-2.8.1', KDE, GTK, Octave, etc.        2200
  724.      megabytes.  The tests conducted are as follows.  Each test means
  725. compressing (a copy of) each file in the data set, decompressing it and
  726. comparing it against the original.
  727.    First, a bunch of tests with block sizes and internal buffer sizes
  728. set very small, to detect any problems with the blocking and buffering
  729. mechanisms.  This required modifying the source code so as to try to
  730. break it.
  731.   1. Data set H, with       buffer size of 1 byte, and block size of 23
  732.      bytes.
  733.   2. Data set B, buffer sizes 1 byte, block size 1 byte.
  734.   3. As (2) but small-mode decompression.
  735.   4. As (2) with block size 2 bytes.
  736.   5. As (2) with block size 3 bytes.
  737.   6. As (2) with block size 4 bytes.
  738.   7. As (2) with block size 5 bytes.
  739.   8. As (2) with block size 6 bytes and small-mode decompression.
  740.   9. H with buffer size of 1 byte, but normal block       size (up to
  741.      900000 bytes).
  742.         Then some tests with unmodified source code.
  743.   1. H, all settings normal.
  744.   2. As (1), with small-mode decompress.
  745.   3. H, compress with flag `-1'.
  746.   4. H, compress with flag `-s', decompress with flag `-s'.
  747.   5. Forwards compatibility: H, `bzip2-0.1pl2' compressing,
  748.      `bzip2-0.9.5' decompressing, all settings normal.
  749.   6. Backwards compatibility:  H, `bzip2-0.9.5' compressing,
  750.      `bzip2-0.1pl2' decompressing, all settings normal.
  751.   7. Bigger tests: A, all settings normal.
  752.   8. As (7), using the fallback (Sadakane-like) sorting algorithm.
  753.   9. As (8), compress with flag `-1', decompress with flag       `-s'.
  754.  10. H, using the fallback sorting algorithm.
  755.  11. Forwards compatibility: A, `bzip2-0.1pl2' compressing,
  756.      `bzip2-0.9.5' decompressing, all settings normal.
  757.  12. Backwards compatibility:  A, `bzip2-0.9.5' compressing,
  758.      `bzip2-0.1pl2' decompressing, all settings normal.
  759.  13. Misc test: about 400 megabytes of `.tar' files with       `bzip2'
  760.      compiled with Checker (a memory access error        detector, like
  761.      Purify).
  762.  14. Misc tests to make sure it builds and runs ok on non-Linux/x86
  763.       platforms.
  764.         These tests were conducted on a 225 MHz IDT WinChip machine,
  765. running Linux 2.0.36.  They represent nearly a week of continuous
  766. computation.  All tests completed successfully.
  767. File: bzip2.info,  Node: Further reading,  Prev: Testing,  Up: Miscellanea
  768. Further reading
  769. ===============
  770.    `bzip2' is not research work, in the sense that it doesn't present
  771. any new ideas.  Rather, it's an engineering exercise based on existing
  772. ideas.
  773.    Four documents describe essentially all the ideas behind `bzip2':
  774.      Michael Burrows and D. J. Wheeler:
  775.        "A block-sorting lossless data compression algorithm"
  776.         10th May 1994.
  777.         Digital SRC Research Report 124.
  778.         ftp://ftp.digital.com/pub/DEC/SRC/research-reports/SRC-124.ps.gz
  779.         If you have trouble finding it, try searching at the
  780.         New Zealand Digital Library, http://www.nzdl.org.
  781.      
  782.      Daniel S. Hirschberg and Debra A. LeLewer
  783.        "Efficient Decoding of Prefix Codes"
  784.         Communications of the ACM, April 1990, Vol 33, Number 4.
  785.         You might be able to get an electronic copy of this
  786.            from the ACM Digital Library.
  787.      
  788.      David J. Wheeler
  789.         Program bred3.c and accompanying document bred3.ps.
  790.         This contains the idea behind the multi-table Huffman
  791.         coding scheme.
  792.         ftp://ftp.cl.cam.ac.uk/users/djw3/
  793.      
  794.      Jon L. Bentley and Robert Sedgewick
  795.        "Fast Algorithms for Sorting and Searching Strings"
  796.         Available from Sedgewick's web page,
  797.         www.cs.princeton.edu/~rs
  798.    The following paper gives valuable additional insights into the
  799. algorithm, but is not immediately the basis of any code used in bzip2.
  800.      Peter Fenwick:
  801.         Block Sorting Text Compression
  802.         Proceedings of the 19th Australasian Computer Science Conference,
  803.           Melbourne, Australia.  Jan 31 - Feb 2, 1996.
  804.         ftp://ftp.cs.auckland.ac.nz/pub/peter-f/ACSC96paper.ps
  805.    Kunihiko Sadakane's sorting algorithm, mentioned above, is available
  806. from:
  807.      http://naomi.is.s.u-tokyo.ac.jp/~sada/papers/Sada98b.ps.gz
  808.    The Manber-Myers suffix array construction algorithm is described in
  809. a paper available from:
  810.      http://www.cs.arizona.edu/people/gene/PAPERS/suffix.ps
  811.